home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93a.txt / 000042_icon-group-sender _Sun Jan 24 02:09:19 1993.msg < prev    next >
Internet Message Format  |  1993-04-21  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Sun, 24 Jan 1993 05:57:30 MST
  2. Date: Sun, 24 Jan 93 02:09:19 MST
  3. From: whm@shepard.sunquest.com (Bill Mitchell)
  4. Message-Id: <9301240909.AA02066@shepard.sunquest.com>
  5. To: icon-group@cs.arizona.edu
  6. Subject: Re: builtin Icon functions
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10.     From: gmt@cs.arizona.edu("Gregg Townsend")
  11.     Date: Sat, 23 Jan 93 11:54:17 MST
  12.     Subject: builtin Icon functions
  13.  
  14.     I am amused by postings that state "I never use X, so I suggest that X
  15.     should be removed from the library".   That's an awfully self-centered
  16.     view.  While I never use acos() or bal(), that doesn't mean that I think
  17.     they should be deleted.
  18.  
  19. Well, I think you need to read between the lines on such statements.  I think
  20. that what's usually meant is that "I never use it and I think most persons
  21. don't use it."
  22.     
  23.     A defensible criterion is the one states "If it can be programmed 
  24.     in Icon, it belongs in the IPL instead of being a builtin function".
  25.     ...
  26.  
  27. But (as you know) if follow that far enough, you're left with only
  28. enough of a language to simulate a Turing machine! 
  29.     
  30.     My own opinion is that a large repertoire of preprogrammed operations
  31.     greatly increases the utility of a language, whether these are supplied
  32.     as operators or builtin functions.  Certainly FORTRAN would not have
  33.     succeeded without its math library.  Accordingly, I support the inclusion
  34.     of tab(), bal(), sin(), detab(), and other functions, and would like to
  35.     see more.
  36.  
  37. I think a too large repertoire *decreases* the utility of the language.  My
  38. canonical example:  The set of functions that come with GNU Emacs Lisp.
  39. It's too much to remember and too much to read!  Every additional feature
  40. adds a little weight.  A little more work to implement, a little more work
  41. to document, a little more documentation to read, a little more to
  42. remember. 
  43.  
  44. I that the challenge in designing programming facilities is to provide a
  45. concise set of facilities that provides good coverage of the problems in
  46. the perceived domain of the language.  If the set's too small, all the users
  47. end up reinventing the wheel.  If too big, well, see above.
  48.  
  49. Ralph once told me (c. 1982) that if I wanted to add a feature to Icon, I'd
  50. have find a feature to throw out.  A few features have been added since then
  51. and mostly to the good of the language, but as a rule to put on the wall,
  52. I think it's a pretty good one.
  53.